Subject: More interoperation issues

From: [email-masked] (Paul Brittain)
Date: Thu, 9 Sep 93 18:40:36 BST

As promised, a few more queries on grey areas in the RFC that may affect
interoperability between DLSw implementations.

Again, if these points have been discussed previously, please point me in the
direction of the appropriate mail that I missed when catching up on events
so far.

CIRCUIT_PENDING state
=====================

The state table for the CIRCUIT_PENDING state on p25 of the RFC shows the
exchange of XIDs and DLC_DGRMs (as DGRMFRAMES).  However when in this state the
DLSw does not have the circuit ID from its partner yet as the REACH_ACK has
not yet been received.

How can a DLSw issue XIDFRAME or DGRMFRAME messages without the partner circuit
ID?  I assume that this is incorrect and such messages cannot flow in
CIRCUIT_PENDING state (though DATAFRAME messages could flow).

CIRCUIT_RESTART and RESTART_PENDING states
==========================================

Conversely, these states do not allow for XID and DGRMFRAME transfer even
though it is the type 2 LLC communications that are being reset not the type 1
communications.

Do you agree that these states should permit the exchange of XIDFRAME and
DGRMFRAME SSP messages?

NETBIOS_NR Messages
===================

Consider the following:

- A circuit already exists between DLS1 and DLS2 for MACA and MACB.

- MACA issues a broadcast Netbios NQ for the name 'NEWCIRC' (for which no
  topology tables exist as it a previously unused name).

- The NETBIOS_NQ is broadcast through the DLSw mesh to DLS2, which obtains
  a Netbios NR for 'NEWCIRC' from MACB.

Which circuit should persist - the original circuit or the new one that
would normally be set up when the NETBIOS_NR is sent from DLS2 to DLS1?
Note that the MAC addresses involved are the same so any mechanism put in
place to solve crossover of circuit setup based on MAC addresses will not
resolve this case.

This case is not covered in  Scott Adams example Netbios connection sequence of
12 August (appended) because the NQ is for a new Netbios name.  A NETBIOS_NQ
is therefore broadcast to all DLSw partners instead of issuing it as a
DGRMFRAME on an existing circuit.  Such a NETBIOS_NQ frame would normally lead
to a new circuit being set up.   However, as above, the NR could be returned
from a MAC for which the appropriate circuit already exists.

An obvious way out of this problem is to allow the Netbios NR to flow back as
a DGRMFRAME on the existing circuit even if the Netbios NQ did *NOT* flow as a
(directed) DGRMFRAME on that circuit.

Can Scott or Steve Klein clarify whether this is how they believe the RFC or
6611 intend this situation to be handled?

(I apologise if Steve subsequently sent a mail that answered this.  My mail
connection was unreliable for a week or so about that time and right now I
can't get a connection to Cary to check in the central record).

Paul Brittain
Data Connection Limited
+44 244 313440

Appended exchanges between Scott Adams and Steve Klein:

>From: "Steve Klein (254-5623)" <[email-masked]>
>To: [email-masked]
>Subject: Revised NETBIOS connect flows.
>Status: RO
>
>Scott, your NETBIOS flows are correct with respect to RFC 1434.
>
>In case you are interested in the current 6611 implementation,
>IBM decided to send NETBIOS_NQs and NETBIOS_NRs when a link is in
>CIRCUIT_ESTABLISHED state (see Note 2 and Note 3 of the second flow).
>This change was made after the release of RFC 1434.
>
>I will be sending out a proposal for a change to the NETBIOS connect
>sequence in a day or two.  This proposal will outline changes that
>IBM is considering for DLSw on the 6611 based on our experiences
>with NETBIOS applications in the field.  I would like to use this
>proposal as a starting point for discussions toward the development
>of a standard that could be adopted by this siglet.
>
>Steve Klein
>
>------------------------------- Referenced Note ---------------------------
>>Subject: Revised NETBIOS connect flows.
>>From: [email-masked] (Scott Adams)
>>Date: Thu, 12 Aug 1993 15:06:23 -0400 (EDT)
>>Message-Id: <[email-masked]>
>>X-Mailer: ELM [version 2.4 PL20]
>>Mime-Version: 1.0
>>Content-Type: text/plain; charset=US-ASCII
>>Content-Transfer-Encoding: 7bit
>>Content-Length: 8678
>>
>>Hello again,
>>
>>I had previously submitted an example of a NETBIOS connect flow.  I've
>>discovered that there were errors in that flow diagram, and I'd like
>>to fix that it and provide a more common connect flow as the primary one.
>>
>>The network looks like:
>>
>>                  +----------+                  +----------+
>>                  |          |      Tunnel      |          |
>>                  |   DLSw   +==================+   DLSw   |
>>                  |    A     |                  |    B     |
>>                  +----+-----+                  +----+-----+
>>                       |                             |
>>                  LAN  |                         LAN |
>>           -------+----+-----               ---------+---+--------
>>                  |                                      |
>>            +-----+-----+                          +-----+-----+
>>            | End Stn 1 |                          | End Stn 2 |
>>            +-----------+                          +-----------+
>>
>>First example connect flow:
>>
>>        End Stn 1         DLSw A                DLSw B         End Stn 2
>>        ---------         ------                ------         ---------
>>           |         [DISCONNECTED]       [DISCONNECTED]          |
>>           | Add_Name_Qry  |    NETBIOS_ANQ      | Add_Name_Qry   |
>>Note 1.    | ------------> | ------------------> | -------------> |
>>           |      .        |         .           |       .        |
>>           |      .        |         .           |       .        |
>>           |      .        |         .           |       .        |
>>           | Name_Qry(C)   |    NETBIOS_NQ       |  Name_Qry(C)   |
>>Note 2.    | ------------> | ------------------> | -------------> |
>>           |         [DISCONNECTED]       [RESOLVE_PEND]          |
>>           |  Name_Rec(L)  |    NETBIOS_NR       |   Name_Rec(L)  |
>>Note 3.    | <------------ | <------------------ | <------------- |
>>           |         [CIRCUT_ESTAB]       [CIRCUIT_PEND]          |
>>           |               |    REACH_ACK        |                |
>>           |               | ------------------> |                |
>>           |               |              [CIRCUIT_ESTAB]         |
>>           |  SABME        |    CONTACT          |  SABME         |
>>Note 4.    | ------------> | ------------------> | -------------> |
>>           |     UA  [CONNECT_PEND]       [CONTACT_PEND]      UA  |
>>           | <------------ |       .             | <------------- |
>>Note 5.    |  RR           |       .             |  RR            |
>>           | ------------> |       .             | -------------> |
>>           |          RNR  |       .      [CONNECTED]         RR  |
>>           | <------------ |     CONTACTED       | <------------- |
>>           |           RR  | <-----------------  |                |
>>           | <------------ |                     |                |
>>           |         [CONNECTED]                 |                |
>>           | Sess_Init     |   I-Frame           |  Sess_Init     |
>>Note 6.    | ------------> | ------------------> | -------------> |
>>           |               |                     |                |
>>           | Sess_Conf     |    I-Frame          |  Sess_Conf     |
>>           | <------------ | <------------------ | <------------- |
>>           |               |                     |                |
>>           |               |                     |                |
>>
>>Note 1.  This is a broadcast Add_Name_Query intended to register its
>>         name and check for conflicts.  If no other end station is
>>         using this name and there are no name conflicts, then it
>>         assumes it can use it.
>>
>>Note 2.  This is a broadcast Name_Query Call packet that is intended
>>         to find out if the destination end station has a LISTEN
>>         outstanding for the source Name.
>>
>>Note 3.  This Name_Recognized indicates that a LISTEN was outstanding,
>>         meaning it's ok to establish a session.
>>
>>Note 4.  The SABME initiates the LLC Type 2 Connection for the NetBIOS
>>         session.
>>
>>Note 5.  I have shown what I think connection establishment would look
>>         like using the immediate UA/RNR response indicated in the
>>         RFC.  Witholding the UA could also be applied here, allowing
>>         the RNR to be dispensed with.
>>
>>Note 6.  The Session_Init packet begins the transmission of I frames
>>         over the new connection, and initiates the NetBIOS session.
>>
>>An  alternative connect sequence (seen from Windows NT) is:
>>
>>[Note that this was the sequence I provided in my original message,
>>with appropriate corrections.  There were two errors.  One was that
>>the SSP pkts sent between DLSw in response to NB_NAME_QUERY/RECOGNIZED
>>pkts after the switches enter CIRCUIT_ESTABLISHED state should be
>>DGRMFRAMEs, not NETBIOS_NQ and NETBIOS_NR.  Also, I left out the
>>REACH_ACK pkt after receipt of the NETBIOS_NR frame.]
>>
>>        End Stn 1         DLSw A                DLSw B         End Stn 2
>>        ---------         ------                ------         ---------
>>           |         [DISCONNECTED]       [DISCONNECTED]          |
>>           | Name_Qry(F)   |    NETBIOS_NQ       | Name_Qry(F)    |
>>Note 1.    | ------------> | ------------------> | -------------> |
>>           |         [DISCONNECTED]       [RESOLVE_PEND]          |
>>           |     Name_Rec  |    NETBIOS_NR       |      Name_Rec  |
>>Note 3.    | <------------ | <------------------ | <------------- |
>>           |         [CIRCUT_ESTAB]       [CIRCUIT_PEND]          |
>>           |               |    REACH_ACK        |                |
>>           |               | ------------------> |                |
>>           |               |              [CIRCUIT_ESTAB]         |
>>           | Name_Qry(C)   |    DGRMFRAME        |  Name_Qry(C)   |
>>Note 2.    | ------------> | ------------------> | -------------> |
>>           |               |                     |                |
>>           |  Name_Rec(L)  |    DGRMFRAME        |   Name_Rec(L)  |
>>Note 3.    | <------------ | <------------------ | <------------- |
>>           |               |                     |                |
>>           |  SABME        |    CONTACT          |  SABME         |
>>Note 4.    | ------------> | ------------------> | -------------> |
>>           |     UA  [CONNECT_PEND]       [CONTACT_PEND]      UA  |
>>           | <------------ |       .             | <------------- |
>>Note 5.    |  RR           |       .             |  RR            |
>>           | ------------> |       .             | -------------> |
>>           |          RNR  |       .      [CONNECTED]         RR  |
>>           | <------------ |     CONTACTED       | <------------- |
>>           |           RR  | <-----------------  |                |
>>           | <------------ |                     |                |
>>           |         [CONNECTED]                 |                |
>>           | Sess_Init     |   I-Frame           |  Sess_Init     |
>>Note 6.    | ------------> | ------------------> | -------------> |
>>           |               |                     |                |
>>           | Sess_Conf     |    I-Frame          |  Sess_Conf     |
>>           | <------------ | <------------------ | <------------- |
>>           |               |                     |                |
>>           |               |                     |                |
>>
>>Note 1.  This is a broadcast Name_Query intended to locate the
>>         destination end station's MAC addr.
>>
>>Note 2.  This is a directed Name_Query Call packet that is intended to
>>         find out if the destination end station has a LISTEN
>>         outstanding for the source Name.
>>
>>Note 3.  This Name_Recognized indicates that a LISTEN was outstanding,
>>         meaning it's ok to establish a session.
>>
>>Note 4.  The SABME initiates the LLC Type 2 Connection for the NetBIOS
>>         session.
>>
>>Note 5.  I have shown what I think connection establishment would look
>>         like using the immediate UA/RNR response indicated in the
>>         RFC.  Witholding the UA could also be applied here, allowing
>>         the RNR to be dispensed with.
>>
>>Note 6.  The Session_Init packet begins the transmission of I frames
>>         over the new connection, and initiates the NetBIOS session.
>>
>>In both scenarios session disconnect is handled as an I frame within
>>the LLC 2 connection (SESSION_END frame), and the LLC 2 connection is
>>disconnected normally.  Once the LLC 2 connection is disconnected then
>>all remnants of the NETBIOS session are gone.
>>
>>These are how I think such connect flows are supposed to work over
>>DLS.  If I'm wrong, PLEASE correct me (particularly those at IBM,
>>who are the only ones with actual experience...).  Thanks,
>>
>>Scott
>>